Bug Fix: NPCs spawned under a target couldn't attack

Summary

NPCs spawned under a target couldn't attack because Interact mode (used for the initial attack interaction) had no logic to step out from under the target, unlike CombatMovement which explicitly handles this case.

Root Cause

When an NPC with allowed_under = false is on the same tile as its target, the following chain of failures occurs:

Fix

Interact.kt (tick()): Before the normal calculate() / processInteraction() flow, check if the NPC is under its target and not allowed there. If so, mirror CombatMovement.stepOut() behavior:

1. Clear any stale steps
2. Pick a random cardinal direction
3. Queue a step in that direction if passable
4. Call super.tick() to execute the step

This lets the NPC move out from under the target on the first tick, allowing combat to initialize normally on the second tick.

Test

CombatMovementTest.kt: Creates a guard NPC spawned at the same tile as a player, calls interactPlayer(player, "Attack"), ticks twice, and verifies the NPC has moved away and transitioned to CombatMovement.

Demo

Bug Fix: Character creation screen skipped for new accounts

Summary

New accounts were not shown the character_creation interface on first login.

Root Cause

AccountManager.create() was setting the "creation" timestamp immediately when a new player record was created. Introduction.welcome() uses the presence of "creation" to detect returning players and skip the screen, so new accounts were being mistaken for returning players before they ever logged in.

Fix

Removed "creation" from AccountManager.create(). The timestamp is already set by Introduction.setup() after the character_creation interface closes, which is the correct point in time. Updated the corresponding test to no longer assert the premature value.

Bug Fix: Dragon claws special attack damage and hit timing

Summary

Fixes the dragon claws "Slice and Dice" special attack (DragonClaws.kt) to match the 2011 behavior. There were three damage formula bugs and a fundamental engine-level timing issue causing all four hits to land on the same tick.

Damage Formula Fixes

Hit Timing Fix

All four hitsplats were landing on the same tick. The spec requires two pairs: hits 1 & 2 on the activation tick, hits 3 & 4 on the following tick (0.6 seconds later).

Root cause: ActionQueue.tick() runs a while (queue.isNotEmpty()) loop that calls removeIf repeatedly, decrementing remaining on every pass. This fast-forwards any delayed actions within the same tick, so initialDelay = 2 would get decremented to 0 over two passes in a single queue.tick() call, regardless of the delay value passed to hit().

Fix: Instead of passing a delay to the final two hit() calls, hits 3 and 4 are now dispatched from inside a strongQueue proxy action on the target. Because strongQueue adds to pending (not queue), and queuePending() only runs at the start of the next queue.tick(), anything added to pending during an active queue.tick() is naturally deferred by one full tick, with no delay arithmetic needed.